rename Memory::get methods to get_raw to indicate their unchecked nature #66043
Conversation
|
r? @cramertj (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ |
|
📌 Commit 0aee0dd has been approved by |
bors
added
S-waiting-on-bors
Yes, it needs |
|
@bjorn3 okay, so we should likely still allow immutable access. But we can shut down mutable access eventually. |
|
I have actually been thinking about allowing the user to mutate state (including allocations) instead of just observing it. However I havent worked on priroda anymore for 5 months according to github. |
|
Maybe renaming the functions to |
|
For now I don't think things are bad enough that we need to resort to leading underscores... |
rename Memory::get methods to get_raw to indicate their unchecked nature Some recent Miri PRs started using these methods when they should not; this should discourage their use. In fact we could make these methods private to the `interp` module as far as Miri is concerned -- with the exception of the `uninit` intrinsic which will hopefully go away soon. @bjorn3 @oli-obk does priroda need these methods? It would be great to be able to seal them away.
|
Toolstate failure in #66138 (comment), @bors rollup=never p=-1 Please revert ^-- in a bit. |
|
A Miri failure shouldn't be a problem even during the beta week...? |
|
🤷♂ -- beats me; it seems to have caused a failure tho... but I think toolstate blockage is finally over. @bors p=0 rollup=maybe |
|
Ah, clippy-driver also got broken in that rollup. Whether that was this PR or another one I don't know. I guess we'll see.^^ |
|
Looks like clippy was affected by another PR in the rollup: #66150 |
|
☔ The latest upstream changes (presumably #66175) made this pull request unmergeable. Please resolve the merge conflicts. |
bors
added
S-waiting-on-author
RalfJung
force-pushed
the
memory-get-raw
branch
from
0aee0dd to
15ec8f7
Compare
|
Rebased. @bors r=cramertj |
|
📌 Commit 15ec8f7 has been approved by |
bors
added
S-waiting-on-bors
|
⌛ Testing commit 15ec8f7 with merge b21093f8fcb2591907a739fd7a05cd8500727521... |
rename Memory::get methods to get_raw to indicate their unchecked nature Some recent Miri PRs started using these methods when they should not; this should discourage their use. In fact we could make these methods private to the `interp` module as far as Miri is concerned -- with the exception of the `uninit` intrinsic which will hopefully go away soon. @bjorn3 @oli-obk does priroda need these methods? It would be great to be able to seal them away.
|
@bors retry rolled up. |
rename Memory::get methods to get_raw to indicate their unchecked nature Some recent Miri PRs started using these methods when they should not; this should discourage their use. In fact we could make these methods private to the `interp` module as far as Miri is concerned -- with the exception of the `uninit` intrinsic which will hopefully go away soon. @bjorn3 @oli-obk does priroda need these methods? It would be great to be able to seal them away.
Rollup of 5 pull requests Successful merges: - #65785 (Transition future compat lints to {ERROR, DENY} - Take 2) - #66007 (Remove "here" from "expected one of X here") - #66043 (rename Memory::get methods to get_raw to indicate their unchecked nature) - #66154 (miri: Rename to_{u,i}size to to_machine_{u,i}size) - #66188 (`MethodSig` -> `FnSig` & Use it in `ItemKind::Fn`) Failed merges: r? @ghost
Some recent Miri PRs started using these methods when they should not; this should discourage their use.
In fact we could make these methods private to the
interpmodule as far as Miri is concerned -- with the exception of theuninitintrinsic which will hopefully go away soon. @bjorn3 @oli-obk does priroda need these methods? It would be great to be able to seal them away.